Network Working Group G. Keeni 
Request for Comments: 5427 Cyber Solutions Inc. 
Category: Standards Track March 2009 


Textual Conventions for Syslog Management 


Status of This Memo 


This document specifies an Internet standards track protocol for the 
Internet community, and requests discussion and suggestions for 


improvements. Please refer to the current edition of the "Internet 
Official Protocol Standards" (STD 1) for the standardization state 
and status of this protocol. Distribution of this memo is unlimited. 


Copyright Notice 


Copyright (c) 2009 IETF Trust and the persons identified as the 
document authors. All rights reserved. 


This document is subject to BCP 78 and the IETF Trust’s Legal 
Provisions Relating to IETF Documents in effect on the date of 
publication of this document (http://trustee.ietf.org/license-info). 
Please review these documents carefully, as they describe your rights 
and restrictions with respect to this document. 


This document may contain material from IETF Documents or IETF 
Contributions published or made publicly available before November 
10, 2008. The person(s) controlling the copyright in some of this 
material may not have granted the IETF Trust the right to allow 
modifications of such material outside the IETF Standards Process. 
Without obtaining an adequate license from the person(s) controlling 
the copyright in such materials, this document may not be modified 
outside the IETF Standards Process, and derivative works of it may 
not be created outside the IETF Standards Process, except to format 
it for publication as an RFC or to translate it into languages other 
than English. 


Abstract 
This MIB module defines textual conventions to represent Facility and 
Severity information commonly used in syslog messages. The intent is 


that these textual conventions will be imported and used in MIB 
modules that would otherwise define their own representations. 


Keeni Standards Track [Page 1] 


RFC 5427 Syslog MIB-TC March 2009 


Table of Contents 


1. The Internet-Standard Management Framework ..............-22 eee 2 
Pee SBACKG EO UMP A, snc trid e tenis ia EE A lar ania cs naineh fot seine: Sarai omens: levee aia wee eee Ate’ a cb AS RRs Tek 2 
33. The Syslog: Textual Conventions MIB swe tgs e EEE Sele ee wenn ea ie 3 
45: Security Consrderat Lons oo seas orale ig ae tied els Ne a Sia we, shale Greve oe OAR E eee 7 
Se TANA: Considerations uesta re e eile at eee, oe a os dre e a oe See ee eh dee eee 7 
©.) REFETENGES: Ws sites otk ASR cals he ie os hh el a a eh Ass ee A ood 8 

6.15 Normative RefereñcEsS eaw esee So ave wlcsahte ce en e odie oo: event. E aliens. a E 8 

6.2% ‘Informative, Referentes sss ce kee ed e eee oe ee ee ee a ee 8 
Te Acknowledgments “belie eos eee eE Ea a Roe eae hE herded) gee ee Sty Se eee doa S 8 

1. The Internet-Standard Management Framework 


For a detailed overview of the documents that describe the current 
Internet-Standard Management Framework, please refer to section 7 of 
RFC 3410 [RFC3410]. 


Managed objects are accessed via a virtual information store, termed 
the Management Information Base or MIB. MIB objects are generally 
accessed through the Simple Network Management Protocol (SNMP). 
Objects in the MIB are defined using the mechanisms defined in the 
Structure of Management Information (SMI). This memo specifies a MIB 
module that is compliant to the SMIv2, which is described in STD 58, 
RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 
[RFC2580]. 


2. Background 


Operating systems, processes, and applications, collectively termed 
"Facilities" in the following, generate messages indicating their own 
status or the occurrence of events. These messages have come to be 
known as syslog messages. A syslog message in general will contain 
among other things a code representing the Facility that generated 
the message and a code representing the Severity of the message. The 
Facility and the Severity codes are commonly used to categorize and 
select received syslog messages for processing and display. The 
Facility codes have been useful in qualifying the originator of the 
content of the messages but in some cases they are not specific 
enough to explicitly identify the originator. Implementations of the 
syslog protocol [RFC5424] that contain structured data elements 
(SDEs) should use these SDEs to clarify the entity that originated 
the content of the message. 


This document defines a set of textual conventions (TCs) that can be 
used to represent Facility and Severity codes commonly used in syslog 
messages. 
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The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", “SHALL NOT", 
"SHOULD", “SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in RFC 2119 [RFC2119]. 


3. The Syslog Textual Conventions MIB 


SYSLOG-TC-MIB DEFINITIONS ::= BEGIN 
IMPORTS 
MODULE-IDENTITY, mib-2 
FROM SNMPv2-SMI ==: [RFC2578] 
TEXTUAL-CONVENTION 
FROM SNMPv2-TC; == [RFC2579] 


syslogTCMIB MODULE-IDENTITY 
LAST-UPDATED "2009033000002" -- 30 March 2009 
ORGANIZATION "IETF Syslog Working Group" 
CONTACT-INFO 
" Glenn Mansfield Keeni 
Postal: Cyber Solutions Inc. 
6-6-3, Minami Yoshinari 
Aoba-ku, Sendai, Japan 989-3204. 
Tel: +81-22-303-4012 
Fax: +81-22-303-4015 
EMail: glenn@cysols.com 


Support Group EMail: syslog@ietf.org 
" 


DESCRIPTION 
"The MIB module containing textual conventions for syslog 
messages. 


Copyright (c) 2009 IETF Trust and the persons 
identified as authors of the code. All rights reserved. 


Redistribution and use in source and binary forms, with or 
without modification, are permitted provided that the 
following conditions are met: 


—- Redistributions of source code must retain the above 
copyright notice, this list of conditions and the 
following disclaimer. 


- Redistributions in binary form must reproduce the above 
copyright notice, this list of conditions and the 
following disclaimer in the documentation and/or other 
materials provided with the distribution. 
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- Neither the name of Internet Society, IETF or IETF 
Trust, nor the names of specific contributors, may be 
used to endorse or promote products derived from this 
software without specific prior written permission. 


THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND 
CONTRIBUTORS ’AS IS’ AND ANY EXPRESS OR IMPLIED 
WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED 
WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR 
PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT 
OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, 
INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES 
(INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE 
GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR 
BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF 
LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT 
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT 
OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE 
POSSIBILITY OF SUCH DAMAGE. 


This version of this MIB module is part of RFC 5427; 
see the RFC itself for full legal notices. 


REVISION "2009033000002" -- 30 March 2009 
DESCRIPTION 


"The initial version, published as RFC 5427." 


{ mib-2 173 } 


SyslogFacility ::= TEXTUAL-CONVENTION 
STATUS current 
DESCRIPTION 


Keeni 


"This textual convention enumerates the Facilities that 
originate syslog messages. 


The Facilities of syslog messages are numerically coded 
with decimal values. For interoperability and backwards- 
compatibility reasons, this document specifies a 

normative mapping between a label, which represents a 
Facility, and the corresponding numeric value. This label 
could be used in, for example, SNMP Manager user 
interfaces. 
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The label itself is often semantically meaningless 

because it is impractical to attempt to enumerate all 
possible Facilities, and many daemons and processes do 

not have an explicitly assigned Facility code or label. 
For example, there is no Facility label corresponding to 
an HTTP service. An HTTP service implementation might log 
messages as coming from, for example, ’local7’ or ’uucp’. 
This is typical current practice, and originators, relays, 
and collectors can be configured to properly handle this 
situation. For improved accuracy, an application can also 
include an APP-NAME structured data element. 


Note that operating system mechanisms for configuring 
syslog, such as syslog.conf, have not yet been standardized 
and might use different sets of Facility labels and/or 
mapping between Facility labels and Facility codes than the 
MIB. 


In particular, the labels corresponding to Facility codes 4, 
10, 13, and 14, and the code corresponding to the Facility 
label ’cron’ are known to vary across different operating 
systems. To distinguish between the labels corresponding 
to Facility codes 9 and 15, a label of ’cron2’ is assigned 
to the Facility code 15. This list is not intended to be 
exhaustive; other differences might exist, and new 
differences might be introduced in the future. 


The mapping specified here MUST be used in a MIB network 
management interface, even though a particular syslog 
implementation might use a different mapping in a 


different network management interface. 
" 


REFERENCE "The Syslog Protocol (RFC5424): Table 1" 


SYNTAX 


Keeni 


INTEGER 
{ 
kern (0), -- kernel messages 
user (1), -- user-level messages 
mail (2), -- mail system messages 
daemon (3), -- system daemons’ messages 
auth (4), -- authorization messages 
syslog (5), -- messages generated internally by 
-- syslogd 
lpr (6), -- line printer subsystem messages 
news (7), -- network news subsystem messages 
uucp (8), -- UUCP subsystem messages 
cron (9), -- clock daemon messages 
authpriv (10),-- security/authorization messages 
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ftp 
ntp 
audit 
console 
cron2 
localO 
locall 
local2 
local3 
local4 
local5 
local6 
local7 


ftp daemon messages 
NTP subsystem messages 
audit messages 

console messages 

-- clock daemon messages 
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} 


SyslogSeverity ::= TEXTUAL-CONVENTION 
STATUS current 
DESCRIPTION 
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"This textual convention enumerates the Severity levels 
of syslog messages. 


The Severity levels of syslog messages are numerically 
coded with decimal values. For interoperability and 
backwards-compatibility reasons, this document specifies 
a normative mapping between a label, which represents a 
Severity level, and the corresponding numeric value. 
This label could be used in, for example, SNMP Manager 
user interfaces. 


The label itself is often semantically meaningless 
because it is impractical to attempt to strictly define 
the criteria for each Severity level, and the criteria 
that is used by syslog originators is, and has 
historically been, implementation-dependent. 


Note that operating system mechanisms for configuring 
syslog, such as syslog.conf, have not yet been standardized 
and might use different sets of Severity labels and/or 
mapping between Severity labels and Severity codes than the 
MIB. 


For example, the foobar application might log messages as 
‘crit’ based on some subjective criteria. Yet the operator 
can configure syslog to forward these messages, even though 
the criteria for ’crit’ may differ from one originator to 
another. This is typical current practice, and originators, 
relays, and collectors can be configured to properly handle 
this situation. 
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REFERENCE "The Syslog Protocol (RFC5424): Table 2" 
SYNTAX INTEGER 
{ 


emerg (0), -- emergency; system is unusable 
alert (1), -- action must be taken immediately 
erit (2), —- critical condition 
err (3), —-- error condition 
warning (4), -- warning condition 
notice (5), —- normal but significant condition 
info (6), —-- informational message 
debug (7) -- debug-level messages 
} 
END 
4. Security Considerations 
This module does not define any management objects. Instead, it 


defines a set of textual conventions which may be used by other MIB 
modules to define management objects. Meaningful security 
considerations can only be written in the MIB modules that define 
management objects. This document has therefore no impact on the 
security of the Internet. Since objects defined using the TCs 
defined in this document may introduce security issues, the user of 
these TCs should read the security considerations section of 
[RFC5424]. 


Bs IANA Considerations 


The MIB modules in this document use the following IANA-assigned 
OBJECT IDENTIFIER values recorded in the SMI Numbers registry: 


Descriptor OBJECT IDENTIFIER value 


syslogTCMIB { mib-2 173 } 
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